1. Field of the Invention
The present invention is related generally to a data processing system and in particular to a method and apparatus for memory management. More particularly, the present invention is directed to a computer implemented method, apparatus, and computer usable program code for using trusted user space pages as kernel data pages.
2. Description of the Related Art
The operating system or kernel is an important component of most data processing systems. The kernel is responsible for managing system resources, such as processors, input/output (I/O) devices, and computer memory. Virtual memory is a memory addressing technique where the operating system presents noncontiguous memory to software as contiguous memory. In other words, virtual memory addresses are not tied to the computer's physical memory. Generally, a memory management unit (MMU) translates virtual memory addresses to physical addresses.
An operating system usually divides virtual memory into kernel space and user space. The kernel space is strictly used by the kernel. The user space is utilized by user applications and utilities. A user application cannot access kernel space directly. Moreover, if the kernel stores data in user space, the data can become corrupted or altered by user applications running in the user space.
Generally, when the kernel gathers data, such as data regarding process performance, the data is written in to the kernel space by the kernel. If a user application in the user space needs to utilize the data, the data is copied out from the kernel space into user space. This process of writing data first into the kernel space and then copying data to the user space consumes processor cycles and results in decreased computer system performance.
For example, profiling is used by processes to determine an approximate amount of processor time each process spends in each function. Profiling also identifies other functions that are called by a function and the frequency each of these functions are called. This information is typically presented in a call graph. A profiler analyzes profiling data gathered by the kernel to generate a profile and call graph for a given process. For example, in UNIX®, a profiler, gprof, can be run to analyze profiling data to generate a flat profile and a call graph for a process.
The process profiling algorithm has been extended to thread level profiling. A thread is a part of a process that can execute independently of other parts or threads of the process. In other words, a single process can have multiple threads. Processes having threads are sometimes referred to as threaded applications.
For threaded applications, thread level profiling is an option by which a user can obtain profiling data for each individual thread that is created for a given process. Thread level profiling can provide an approximate time that was spent in each function by individual threads. However, the problems inherent in process level profiling can also be seen in thread level profiling implementations.
When profiling data is collected for a thread and a different user thread needs to be scheduled, the profiling data is copied back to the user space. This copy-in and copy-out activity consumes processor cycles.
Memory usage for thread level profiling is also very high. For example, profiling data for each individual thread identifier (ID) stays in memory until the process exits. The memory consumed by a given thread for storing profiling information remains resident in memory even after the thread has exited. This profiling data for a given thread is only written out of memory to an output file when the parent process exits. This retention of a given thread's profiling data after the given thread has exited is an unnecessary consumption of memory, especially when the given thread's profiling data is ready to be written out but must remain resident in temporary memory until the parent process exits. The large memory requirements for profiling can limit the number of threads that can be created while a profiling feature is active.
Moreover, when a thread ID for a thread is reused on a subsequent thread, the existing profiling data in memory associated with the first thread is updated with the new profiling data for the subsequent thread. The actual profiling data for the first thread occurrence is lost because it is overwritten by the subsequent profiling data. This occurs due to the fact that thread profiling data is not written out to an output file until all threads have executed and the parent process exits.
In addition, thread level profiling data is temporarily stored in the user heap. The user heap can be corrupted by user applications. Therefore, thread profiling data in the user heap can become corrupted. In such a case, a user might unknowingly be using corrupted profiling data for an analysis or other purposes. Finally, all per-thread profiling data is written out at process exit. Therefore, a performance hit will occur during process exit due to the volume of profiling data that is written out at one time.